While the Internet continues its unprecedented exponential growth, the recent broad adoption of always-on broadband technologies such as Digital Subscriber Line (“DSL”) and cable modems, coupled with the pending integration of personal data assistants (“PDAs”) and mobile phones into always-addressable mobile information appliances, significantly elevates the urgency to expand the address space that Internet-connected systems use to communicate. The address space currently used is defined as part of the Internet Protocol, or the IP (the network layer of the TCP/IP (Transport Control Protocol/Internet Protocol) protocol suite. The version of IP commonly used today is Version 4 (“IPv4”), which has not been substantially changed since RFC 791 (Request for Comments under the Internet Engineering Task Force, or “IETF”) was published in 1981. Over that time, IPv4 has proven to be robust, easily implemented and interoperable, and has stood the test of scaling an internetwork (a network of networks) to a global utility the size of today's Internet. While this is a tribute to its initial design, moving forward to an even grander scale requires laying a new foundation.
IPv6 will continue the tradition of the IPv4 protocol, which gained much of its acceptance by defining mechanisms to tie systems together over a wide variety of disparate networking technologies. Already defined link-layer mappings for transporting IPv6 include Ethernet, Point-to-Point Protocol (“PPP”), Fiber Distributed Data Interface (“FDDI”), Token Ring, Asynchronous Transfer Mode (“ATM”), Frame Relay, IEEE 1394 (Institute of Electrical and Electronics Engineers), and IPv4. From the architectural perspective, an IPv4-based infrastructure appears to IPv6-enabled systems as a single segment non-broadcast multi-access (“NBMA”) network. The capability to send IPv6 traffic over existing IPv4 networks will provide an initial reach as broad as the current Internet, limited only by the endpoints' ability and readiness to make use of it.
To address concerns about security and privacy, IPv6 includes IP layer security known as Internet Protocol security (IPsec). IPsec is an industry standard security technology that provides for data authenticity and integrity as well as data confidentiality across the array of protocols used by the various applications. Providing the capability at the network layer frees the developer from having to add specific security capabilities to every application.
New capabilities such as scoped addresses (useful for restricting the default range of file and printer sharing), stateless autoconfiguration (lowering the complexity and management burden), and mandatory IP security (permitting end-to-end data authentication and integrity and privacy of connections) are expected to drive rapid adoption. In addition to the new capabilities, the technologies currently used to extend the lifetime of IPv4—such as Network Address Translators (“NATs”)—frequently break existing applications, and are already restricting the flexibility to deploy new ones. NATs are popular today because they allow multiple systems to share a single scarce public IPv4 address, but in doing so they tend to enforce a client/server usage model where the client uses private address space with only the server existing in public address space. IPv6 brings back the capability of “end-to-end control of communications” making networking applications simpler as the network again becomes transparent.
The conversion from IPv4 to IPv6 is anticipated to be a larger task for the industry than the preparation for Year 2000. It will affect nearly all networked applications, end-systems, infrastructure systems, and network architectures. It is critical that this change be approached with responsibility to prevent costly unproductive missteps that result from broad premature availability of technologies. Unlike the Year 2000 issue, the conversion to IPv6 has no specific timeline. However, as noted earlier, the rate of IPv4 address consumption is rapidly increasing. Simplicity of deployment will be the key to rapid adoption.
The migration of IPv4 to IPv6 will not happen overnight. There will be a period of transition when both protocols are in use over the same infrastructure. To address this transition period, the designers of IPv6 have created technologies and address types so that IPv6 nodes can communicate with each other in a mixed environment, even if they are separated by an IPv4-only infrastructure.
RFC 2893 defines a variety of different node types. An IPv4-only node implements only IPv4 (and has only IPv4 addresses) and does not support IPv6. Most hosts and routers installed today are IPv4-only nodes.
An IPv6-only node implements only IPv6 (and has only IPv6 addresses) and does not support IPv4. This node is only able to communicate with IPv6 nodes and applications. This type of node is not common today, but might become more prevalent as smaller devices such as cellular phones and handheld computing devices include the IPv6 protocol.
An IPv6/IPv4 node implements both IPv4 and IPv6.
An IPv4 node implements IPv4. An IPv4 node can be an IPv4-only node or an IPv6/IPv4 node.
An IPv6 node implements IPv6. An IPv6 node can be an IPv6-only node or an IPv6/IPv4 node.
For coexistence to occur, the largest number of nodes (IPv4 or IPv6 nodes) can communicate using an IPv4 infrastructure, an IPv6 infrastructure, or an infrastructure that is a combination of IPv4 and IPv6. True migration is achieved when all IPv4 nodes are converted to IPv6-only nodes. However, for the foreseeable future, practical migration is achieved when as many IPv4-only nodes as possible are converted to IPv6/IPv4 nodes. IPv4-only nodes can communicate with IPv6-only nodes only when using an IPv4-to-IPv6 proxy or translation gateway.
While such gateways can often perform satisfactorily, they often represent an additional expense compared with native IPv6 implementations. And because the IPv4-to-IPv6 proxy or translation gateway needs to terminate the IPsec connection for encrypted traffic before translation can be performed, the link between the gateway and IPv4 infrastructure can pose a security vulnerability in some cases. In addition, use of the gateway typically causes confusion in a given domain with regard to Domain Name System (“DNS”) infrastructure because the IPv4 infrastructure will register with DNS servers in the domain as an IPv4 server, for example, even though the gateway supports IPv6. Upgrading DNS infrastructure to deal with mixed IPv4/IPv6 capabilities is not a trivial undertaking and represents additional costs.
This Background is provided to introduce a brief context for the Summary and Detailed Description that follow. This Background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above.